[00:00.000 --> 00:04.500]  Thanks for tuning into my talk. This is Houston, we have a problem.
[00:04.740 --> 00:09.060]  It's a bit weird doing things this way, but I guess this is going to be the new normal now.
[00:09.480 --> 00:14.000]  So the title of my talk is Houston, we have a problem. I'm here today to talk to you about
[00:14.000 --> 00:19.260]  Europe's proposals for future intelligent roadways to support connected and autonomous vehicles.
[00:25.160 --> 00:28.040]  So overview of what I'm going to talk about in this session.
[00:28.160 --> 00:32.360]  First up, who am I? And where did this project come from?
[00:32.360 --> 00:36.640]  Then a large portion of this talk is going to be discussing the proposed CAV ecosystem.
[00:37.160 --> 00:40.880]  There's a lot of proposed components in these future systems.
[00:40.900 --> 00:44.280]  So you need to kind of know what all the components are before you can understand
[00:44.280 --> 00:48.660]  the overarching system. I'm also going to be shit talking them as I go.
[00:48.820 --> 00:53.340]  From here, I'm going to be discussing some of the threats likely to be faced by the ecosystems.
[00:53.340 --> 00:57.420]  So who's likely to target them, with what resources and what kind of things they're
[00:57.420 --> 01:01.480]  going to be going after. I'll talk through some example scenarios of how an attacker
[01:01.480 --> 01:06.660]  might infiltrate the network and what to expect. Next up, I'll provide considerations for how we
[01:06.660 --> 01:12.560]  can improve the situation. And finally, the conclusions, which, spoiler alert, is mainly
[01:12.560 --> 01:16.940]  that everything is nightmare. Then we'll have some acknowledgments and time for questions,
[01:16.940 --> 01:23.680]  which I believe is going to be all types. So a little about me. My name is Vic Harkness.
[01:23.800 --> 01:28.960]  I've got a degree in robotics and artificial intelligence and a degree in cyber security.
[01:28.960 --> 01:34.920]  I also worked as a falconer for a bit. After graduating, I worked for DSTL, which is a bit of
[01:34.920 --> 01:40.720]  the UK Ministry of Defence, then moved to MWR Info Security. That got purchased by F-Secure,
[01:40.720 --> 01:45.600]  so now I work at F-Secure. And I was the lead author on the bit of work that this talk is
[01:45.600 --> 01:50.620]  discussing. If you want to talk to me, you can find me on Twitter at Vic Harkness. Talk to me
[01:50.620 --> 01:56.120]  about falconry, facial recognition systems, biometrics, and network vehicle security.
[01:58.300 --> 02:03.960]  So an overview of the project. This package of work was done as part of the ZENZIC Cyber
[02:03.960 --> 02:09.860]  Feasibility Report Project. So the ZENZIC Cyber Feasibility Report Project aims to inform and
[02:09.860 --> 02:15.480]  advise the UK government on the security of future CAV and ITS networks. So I know I've said CAV a
[02:15.480 --> 02:26.100]  few times already. I'm going to expand on it now. CAV means connected and autonomous vehicles. ITS,
[02:27.060 --> 02:31.940]  they're referring to the same general concept. But some people prefer to say CAV, some prefer to say
[02:31.940 --> 02:36.720]  ITS. I think they're more commonly called ITS. And within the standards documents, they're called
[02:36.720 --> 02:42.360]  ITS. But ZENZIC prefers to call them CAV. So throughout this talk, I'll largely be calling
[02:42.360 --> 02:49.380]  them CAV. So as I'm sure you're aware, automated vehicles are becoming a thing. In the future,
[02:49.380 --> 02:53.100]  it's envisioned that most people will drive either hyperconnected vehicles or have an
[02:53.100 --> 02:58.000]  automated vehicle. To support this future, the creation of sensor-rich intelligent roadways has
[02:58.000 --> 03:02.960]  been proposed. The UK government wants to buy into this future. They don't necessarily want
[03:02.960 --> 03:06.920]  to be the first people to create these intelligent roadway systems, but they want to be the best to
[03:06.920 --> 03:11.000]  do it. They want the most robust roadways, and they want them to be the most secure.
[03:11.220 --> 03:16.280]  And the ZENZIC Cyber Feasibility Report feeds into this goal. So seven companies worked on the
[03:16.280 --> 03:21.340]  problem space, and ZENZIC created a summary report. This summary report went off to government to help
[03:21.340 --> 03:27.300]  decide what they should do about future roadways. So my team at F-Secure looked at the V2X, or
[03:27.300 --> 03:32.040]  vehicle-to-everything aspect of the problem, as well as considering how you might test these future
[03:32.040 --> 03:36.860]  networks at scale. But to understand the problem, we needed to look at the space as a whole.
[03:36.920 --> 03:41.340]  So our paper provides an overview of the entire space, as well as making recommendations on
[03:41.340 --> 03:45.920]  testing at scale. There should be a link to the white paper available by the time you're watching
[03:45.920 --> 03:50.060]  this. At the time of recording, it's not gone live yet, but I'm sure I can share it in the chat or
[03:50.060 --> 03:56.980]  something like that. As a quick note, the proposals we looked at for future cap infrastructure have
[03:56.980 --> 04:02.420]  been provided by the European Telecommunications Standards Institute, the International
[04:03.440 --> 04:09.160]  Organization for Standardization, and the European Commission. So it's a fairly Europe-centric
[04:09.160 --> 04:14.580]  presentation, I'm afraid. But there are very similar proposals in the US, and there's kind
[04:14.580 --> 04:19.940]  of a lot of equivalency between the proposals. So hopefully it's still useful for non-European
[04:19.940 --> 04:24.800]  people. But hopefully this talk and our white paper provide sufficient information for someone
[04:24.800 --> 04:28.700]  wishing to enter the problem space to get up to speed on the future proposals.
[04:32.340 --> 04:35.960]  So first we're going to talk about the CAV ecosystem components.
[04:36.700 --> 04:40.900]  Whilst our area of the project was dealing with the vehicles-to-everywhere communications,
[04:40.900 --> 04:45.460]  I still consider the internal systems of a vehicle as an important part of the CAV ecosystem.
[04:45.900 --> 04:49.740]  Vehicles are no longer expected to be used solely as a means of transportation.
[04:49.740 --> 04:54.320]  They guide us to our destinations using maps. They advise us on the best route to take using
[04:54.320 --> 05:00.340]  traffic information. They advise us, they entertain us using audio and video. In the future, they will
[05:00.340 --> 05:05.200]  ease the burden of driving altogether by being able to autonomously navigate to our destinations.
[05:05.380 --> 05:10.480]  To facilitate this, vehicles contain complex internal networks. Future vehicles are more
[05:10.480 --> 05:15.040]  akin to computer networks. Lots of smaller computers all working on smaller parts of the task
[05:15.040 --> 05:19.340]  network together. So for instance, you could have one computer that's driving the infotainment
[05:19.340 --> 05:23.640]  system, another one that's driving the lights, but they all need to be connected so that the
[05:23.640 --> 05:28.260]  infotainment system can be used to control the lights, for instance. These future vehicles will
[05:28.260 --> 05:32.680]  be handling large amounts of data taken from a range of sources. Some of those are going to be
[05:32.680 --> 05:39.340]  external, like GPS data, traffic data, data coming in from the vendor, whoever you bought the car off.
[05:39.340 --> 05:43.640]  There's also internal data sources within the vehicle. So you've got your classic integrated
[05:43.640 --> 05:49.720]  sensors, like your speed sensors, your tire pressure sensor. But the more futuristic
[05:49.720 --> 05:55.380]  systems are going to have cameras, range sensors, like sonars to detect where there's nearby
[05:55.380 --> 06:00.940]  vehicles or detect if someone's walked in front of the car. And you'll also be taking inputs from the
[06:00.940 --> 06:05.560]  driver of the car, like steering wheel, pressing brakes, that sort of thing.
[06:06.080 --> 06:10.240]  Some of the proposals we looked at also expected some more novel sensors to be used.
[06:10.240 --> 06:15.520]  So one of the proposals actually described a system whereby the car can automatically
[06:15.520 --> 06:20.840]  monitor the biometrics of the user. And so if the driver of the car was to, for instance,
[06:20.840 --> 06:25.160]  have a heart attack, the system would be able to automatically detect and communicate this and
[06:25.160 --> 06:30.820]  assumedly call an ambulance. But with all this data coming from a wide range of sources,
[06:30.820 --> 06:35.400]  how can you trust it? It's a given that attackers are going to be targeting the
[06:35.400 --> 06:40.140]  internal vehicle networks. I'm not going to talk specifically about data hygiene within
[06:40.140 --> 06:43.900]  internal vehicle networks, because I'm sure there'll be someone else at the car hacking village
[06:43.900 --> 06:48.100]  who knows a lot more about it than me and will be able to do a much better job than me of explaining
[06:48.100 --> 06:53.600]  it. But in general, I will say, handle the data with care. No component should place absolute
[06:53.600 --> 06:58.540]  trust in the data it receives. But really, it's up to you guys making these systems to decide how
[06:58.540 --> 07:03.800]  trustworthy components are and design your models based around that trust. Some of the sort of
[07:03.800 --> 07:08.700]  things that an attacker is likely to target are the vehicle sensors, they make a good potential
[07:08.700 --> 07:13.580]  entry point for introducing false or malicious data into the vehicle network. I mean, people
[07:13.580 --> 07:18.000]  are already playing around with the future systems, like people have been using adversarial
[07:18.000 --> 07:23.100]  examples to generate stickers they can put on road signs, which will cause the car to no longer
[07:23.100 --> 07:28.380]  classify the road sign correctly. So what was once a stop sign is now a speed limit sign,
[07:28.380 --> 07:35.040]  the car just drives straight through. Another thing the attackers might target are the entertainment
[07:35.040 --> 07:41.520]  and infotainment systems. They're another good route for introducing malicious data into or
[07:41.520 --> 07:45.880]  gaining access into connected vehicles. I mean, we're already getting familiar with the advanced
[07:45.880 --> 07:51.040]  infotainment systems, we're used to them having a touchscreen now to display maps to play with
[07:51.040 --> 07:56.080]  our music, all that sort of thing. In some of the CAV proposed documents, these systems are also
[07:56.080 --> 08:00.020]  going to be doing tourist information for you, you're going to drive past a mountain, and the
[08:00.020 --> 08:04.520]  car's going to start telling you what the mountain is, the history of it, all about it, for better or
[08:04.520 --> 08:11.440]  worse. Potentially, they're kind of similar to sensors in the attackers might try and manipulate
[08:11.440 --> 08:17.400]  data by and manipulate behavior, sorry, by inserting malicious data, such as incorrect traffic data,
[08:17.400 --> 08:21.220]  or try and use them as a point from which they could pivot to elsewhere within the car's internal
[08:21.220 --> 08:26.900]  network. The first thing I want to mention is applications, because you've got to have apps if
[08:26.900 --> 08:32.040]  you want to be futuristic with your system. So in the Envisioned Future Connected and Autonomous
[08:32.040 --> 08:36.460]  Vehicles, you'll be able to download apps from an app store, like how you would on your phone.
[08:36.460 --> 08:41.240]  And we all know how good that is for device security. There's little information so far on
[08:41.240 --> 08:45.520]  how these will actually look in terms of security and access permission models. Don't know if it's
[08:45.520 --> 08:49.120]  going to be like the Apple Store, where you've got to like have your app pre-approved before it can
[08:49.120 --> 08:52.620]  be uploaded. Or if it's going to be a bit more like the Android Store, where you can just kind
[08:52.620 --> 08:57.880]  of go for it. There's no advice on this at this point. But it does seem like they're going to be
[08:57.880 --> 09:02.460]  an excellent route to break into a vehicle's internal network. I mean, they might end up
[09:02.460 --> 09:09.100]  being used as part of a jailbreaking solution for the vehicles. So with Teslas, it turns out
[09:09.100 --> 09:13.820]  that when you buy an upgrade for a Tesla, it can be remotely enabled, you don't actually need
[09:13.820 --> 09:19.760]  to go to the garage to get it upgraded. So when they had the massive fires in California a few
[09:19.760 --> 09:25.600]  years back, Tesla remotely pushed free battery updates to cars within the area of effect,
[09:25.600 --> 09:31.060]  so that they could escape easier, or the drivers could escape easier. But the Lord Elon giveth,
[09:31.060 --> 09:35.600]  the Lord Elon taketh away. There's been lots of cases of people buying secondhand Tesla models
[09:35.600 --> 09:40.780]  with certain upgrades enabled, only to have them be remotely disabled again after purchase.
[09:40.780 --> 09:44.800]  Perhaps applications will be used for this sort of functionality in future paths.
[09:44.900 --> 09:48.940]  Certainly seems like a fun area for future investigation, if nothing else.
[09:50.280 --> 09:55.260]  So what if someone manages to compromise multiple aspects of a vehicle's internal network at once?
[09:55.420 --> 10:00.460]  The vehicles ideally should be able to detect this and handle it in some way. Because it's not
[10:00.460 --> 10:03.820]  really the best solution if it just crashes into a wall because it thinks it's the road,
[10:03.820 --> 10:08.440]  Wile E. Coyote style. Perhaps it'd be more appropriate for a vehicle that detects anything
[10:08.440 --> 10:13.060]  funky going on to drive to the side of the road and refuse to move again until it gets assistance.
[10:13.260 --> 10:16.480]  Or is that just going to be a perfect vector for denial of service attacks?
[10:16.540 --> 10:20.600]  Going to be really annoying and not answer that. Instead, I'll move on to talking about
[10:20.600 --> 10:31.420]  personal stations. So the Etsy standards propose the use of personal stations.
[10:32.460 --> 10:36.140]  These are little handheld devices which are designed to be connected to the overarching
[10:36.140 --> 10:41.060]  cab networks. The exact purpose of them is unclear, but they seem to basically be mobile
[10:41.060 --> 10:46.160]  phones, like you can install apps on them. It's suggested they're used by low-speed users of
[10:46.160 --> 10:51.060]  networks such as pedestrians and cyclists. I've got a few of the suggestions on the slides, like
[10:51.060 --> 10:56.160]  using them to check bus times, use them to update bus times, use them to look at maps.
[10:56.160 --> 11:00.540]  They're basically mobile phones. Maybe this will just morph into an app that you can put on your
[11:00.540 --> 11:04.940]  own mobile phone so you don't have to carry something extra around. Who knows? As far as
[11:04.940 --> 11:09.360]  security goes, I'd say treat them like mobile phones. They're likely to be an easy target for
[11:09.360 --> 11:13.580]  because they're quite small, so you want them to be lockable and remotely trackable.
[11:13.940 --> 11:17.520]  You also, again, don't want to be completely trusting of data coming from them because
[11:17.520 --> 11:24.870]  there's a high risk of compromise if they are akin to mobile phones. So the envisioned future
[11:24.870 --> 11:29.270]  intelligent roadways will need lots and lots of supporting infrastructure. Infrastructure to
[11:29.270 --> 11:33.310]  support the connections between connected vehicles, infrastructure to support the automated
[11:33.310 --> 11:38.550]  decision-making capabilities of automated vehicles. But not all vehicles will be connected
[11:38.550 --> 11:42.590]  or automated in the future. You're still going to get the people like me who are scared of new
[11:42.590 --> 11:47.470]  technology and want something more old-fashioned. Unfortunately, you can't quite ignore us weirdos
[11:47.470 --> 11:51.630]  who refuse to join the borg. You still need to know where the old-fashioned vehicles are so that
[11:51.630 --> 11:55.950]  they can be incorporated into your traffic models or avoided by your automated systems.
[12:00.330 --> 12:05.690]  Extensions of current CCTV and radar system capabilities, when augmented by additional
[12:05.690 --> 12:10.730]  sensors, could be sufficient to track old-fashioned vehicles as though they were connected vehicles.
[12:10.890 --> 12:15.350]  In addition to tracking vehicles, sensors can be used to provide supplementary data into
[12:15.350 --> 12:20.030]  decision-making systems. For example, local weather information or information on road
[12:20.030 --> 12:25.710]  conditions could be useful to augment the data already within the systems. It's also quite useful
[12:25.710 --> 12:30.310]  for automated systems. So if you've got a human driver, they might, you know, notice that it's
[12:30.310 --> 12:35.430]  raining and the road is wet and so automatically slow down. Whereas an automated system, it doesn't
[12:35.430 --> 12:40.450]  work quite like the human does. But if it was receiving data saying the road's wet, slow down,
[12:40.450 --> 12:47.190]  then it will be able to act on that. So thanks to these prolific sensors, it might be the case that
[12:47.190 --> 12:52.990]  these automated systems would be able to behave in a more human-like manner. But unfortunately,
[12:52.990 --> 12:56.170]  just covering everything with sensors means you've got more things to secure.
[12:57.410 --> 13:02.890]  So just go search for CCTV on Showdown if you're bored. You can view the CCTV feeds, which isn't
[13:02.890 --> 13:07.750]  that bad. You know, you'd just be watching cars go along the road. Not really that worrisome. But some of
[13:07.750 --> 13:12.210]  these cameras are designed to be remotely administered. You get that traditional admin-admin
[13:12.210 --> 13:16.150]  credentials combo going and suddenly you have access to a node within the CAV network.
[13:16.450 --> 13:21.690]  If the network trusts data coming from that CCTV system to a high degree, then the whole network's
[13:21.690 --> 13:26.750]  going to be having a bad time. So just, if you're going to be making sensors that are likely to
[13:26.750 --> 13:32.550]  end up in CAV networks, please secure them. Don't have easily guessable default creds. Require admins
[13:32.550 --> 13:38.570]  to use VPNs to remotely administer them. Just do something, please. It seems like it's going to be a
[13:38.570 --> 13:43.570]  really easy way for attackers to get into the networks.
[13:43.570 --> 13:49.370]  Next up, we've got roadside units. So these roadside units, or RSUs, are designed to collect,
[13:49.370 --> 13:53.690]  collate, and forward data from other bits of the network. They'll be taking the data from pretty
[13:53.690 --> 13:58.270]  much everything in the network. They can collect data from roadside sensors and vehicles, and
[13:58.270 --> 14:03.530]  they'll send this data onwards to data hubs, which are processing centers designed to inform
[14:03.530 --> 14:09.770]  traffic control decisions. The RSUs can also take data from vendors and transmit it back down to the
[14:09.770 --> 14:15.670]  vehicles. RSUs are actually physical units proposed to be positioned every 500 meters along the side
[14:15.670 --> 14:21.250]  of the intelligent roadway. They'll all be connected up in some manner. Some believe that RSUs should
[14:21.250 --> 14:25.050]  be able to take more active roles within the network, such as directly controlling autonomous
[14:25.050 --> 14:30.030]  vehicles. I think that's kind of a bad idea for reasons that, you know, should become even more
[14:30.030 --> 14:37.110]  clear as this talk goes on. The RSUs are envisioned to contain some heavy-duty networking equipment,
[14:37.110 --> 14:42.830]  including industrial network switches and ITS station border routers. You want the industrial
[14:42.830 --> 14:50.370]  network switches to be survivable in the harsh environments of constant outdoor usage.
[14:50.550 --> 14:54.650]  And they also support standard security features, such as MAC address filtering,
[14:54.650 --> 15:01.310]  remote management, network access, etc. During this study, we read a report that was investigating
[15:01.310 --> 15:07.650]  the security at one of these proposed roadside units. And they found that, yeah, the switch in it
[15:07.650 --> 15:12.950]  had MAC address filtering in place, but the MAC address of the computer driving the RSU was written
[15:12.950 --> 15:22.110]  on the side of the box, so not really the best security maybe. The ITS station border routers
[15:22.110 --> 15:26.490]  within the RSUs are designed as the point through which data from the intelligent roadways
[15:26.490 --> 15:31.450]  is sent off to the data hubs. There's a few proposals of what form this transport medium
[15:31.450 --> 15:37.130]  could take. Some suggest using LTE. Others suggest that you could just lease actual physical lines
[15:37.130 --> 15:42.570]  from local councils. There's lots of different approaches, and with different approaches come
[15:42.570 --> 15:47.230]  different security concerns. But when you're securing these RSUs, you should take a general
[15:47.230 --> 15:52.350]  network infrastructure security approach. So consider the physical security. Make the locks
[15:52.350 --> 15:58.430]  on the physical box secure with a tamper detection system. If the RSU is hidden away behind the trees,
[15:58.430 --> 16:04.230]  monitor them with CCTV systems. So in the report where they noticed the MAC address was written
[16:04.230 --> 16:09.670]  on the side of the box, the guy who did that study, he actually set up a tent next to the RSU,
[16:09.670 --> 16:14.090]  and he camped out there for like two days, and no one noticed him messing around with the thing.
[16:14.090 --> 16:18.230]  So you need some kind of monitoring, because two days gives you quite a bit of time to play around
[16:18.230 --> 16:23.730]  with stuff. Make sure that tamper detections are actually followed up upon. So you could
[16:23.730 --> 16:29.150]  cross-reference things like timings of tamper detections with maintenance schedules. And if
[16:29.150 --> 16:33.930]  the tamper is determined to not be a false alarm, you should take action. For instance, you could
[16:33.930 --> 16:38.670]  consider that all data from that node is now unsafe, and so do not make any important decisions
[16:38.670 --> 16:43.990]  based upon it. In addition to physical security, you should also follow good network security
[16:43.990 --> 16:49.330]  best practices. You know, change default creds, disable unused services, all that good stuff.
[16:49.570 --> 16:54.690]  Make sure that a procedure for patching devices is in place, encrypt the data being held locally,
[16:54.690 --> 16:58.050]  and when it's being transmitted onwards, especially if you're making use of third-party
[16:59.010 --> 17:03.830]  transmission mediums. Tangentially, you should consider the security of device maintenance
[17:03.830 --> 17:09.090]  systems. It's likely that there'll be engineers coming to, you know, do upgrades on these systems,
[17:09.090 --> 17:13.990]  or do general maintenance tasks, or whatever, really. The engineers carrying out the legitimate
[17:13.990 --> 17:18.950]  work upon the RSUs will probably have laptops that they're designed to plug into the system.
[17:19.090 --> 17:22.810]  They might also have been on a dodgy porn website in the hotel the night before, and be bringing
[17:22.810 --> 17:27.810]  all sorts of nasties with them. So again, just don't trust things. Don't trust an engineer's
[17:27.810 --> 17:35.790]  laptop, even though in theory it should be fine. It might not be. Trust no one, not even yourself.
[17:35.790 --> 17:40.690]  I know I sound like a broken record, but do not place absolute trust in any single aspect of the
[17:40.690 --> 17:53.440]  system. So data hubs are where all the data lives. The data collated by the RSUs
[17:53.440 --> 17:58.460]  will end up here. The scales of the data hubs is kind of unclear right now. I mean, maybe they're
[17:58.460 --> 18:02.680]  going to be regional, maybe they'll be countrywide, maybe they'll be just for a town or a specific
[18:02.680 --> 18:08.640]  section of road. It's not really clear. It's also not clear who's going to run the data hubs,
[18:08.640 --> 18:13.140]  or what exactly they'll be doing with the data. But generally, they're probably going to be used
[18:13.140 --> 18:18.300]  in traffic management systems, traffic analysis, all that good stuff. There's also proposals for
[18:18.300 --> 18:23.260]  their usage in test beds. I'll be talking a bit more about the test beds later. But the basic
[18:23.260 --> 18:27.960]  idea is that there'll be regions of roadways, which are designated for vendors to test their
[18:27.960 --> 18:33.180]  new kit on. Because of this, there's going to be large amounts of data being collected on the test
[18:33.180 --> 18:38.900]  bed roadways, which vendors can then evaluate like post trial to work out the performance of
[18:38.900 --> 18:43.980]  their systems. And that will make test bed data hubs a really high value target for attackers,
[18:43.980 --> 18:48.240]  because there's going to be lots and lots of data. And because people are going to be testing new
[18:48.240 --> 18:52.020]  models of vehicles, it's likely to be about things that aren't actually available yet.
[18:52.020 --> 18:56.800]  So it'd be great for corporate espionage. Or I mean, what if you could just get into the data
[18:56.800 --> 19:00.800]  hub and delete all the data in it? You know, could you force a vendor to have to redo trials and
[19:00.800 --> 19:07.140]  delay the release of a new product? Security of the data hubs is going to be incredibly important.
[19:07.180 --> 19:11.220]  And it's likely going to be fairly bespoke. I mean, one could probably learn from security
[19:11.220 --> 19:16.540]  best practices for any large scale sensitive data holder. But I mean, just once again,
[19:16.540 --> 19:20.340]  you don't want to trust all the data you're receiving into these data hubs,
[19:20.340 --> 19:27.140]  just in general. You know, don't let little bobby tables ruin your day. Likewise, you need some form
[19:27.140 --> 19:31.940]  of accountability within the system. If you find that you're all you're frequently getting malicious
[19:31.940 --> 19:36.680]  data from a certain node, like you're frequently getting bobby tables popping up, you might you
[19:36.680 --> 19:40.960]  want to be able to identify what node this malicious data is coming from. So you can actually
[19:40.960 --> 19:45.820]  address it. Or just if you're getting like, I don't know, like invalid data coming from a node,
[19:45.820 --> 19:50.500]  you want to be able to work out where it's coming from, and address whatever the issue is.
[19:57.220 --> 20:02.500]  So transmission medium, there's the potential for lots of different data transmission media to be
[20:02.500 --> 20:06.800]  used within these future networks. I'll be talking about the connection issues within the next
[20:06.800 --> 20:12.600]  section, when I discuss the bespoke protocols that have been proposed. So LTE is like the most
[20:12.600 --> 20:18.040]  obvious connectivity choice. It's simple, it's fairly accessible nowadays, it's reasonably cheap.
[20:18.100 --> 20:23.020]  Some vehicles already make use of LTE. You've got systems such as eCall, which automatically calls
[20:23.020 --> 20:28.260]  the emergency services if it detects you're in a crash. And LTE can also be used to transmit
[20:28.260 --> 20:33.120]  over-the-air software to vehicles, software updates, sorry, to vehicles. I mean, in future
[20:33.120 --> 20:37.940]  cab vehicles, LTE will probably be used by applications, and maybe also by some of the
[20:37.940 --> 20:43.800]  roadside sensors, who knows. Standard LTE security best practices should be followed, just to make
[20:43.800 --> 20:48.640]  sure it's not too obvious that your tech is using 5G LTE, so it doesn't get blamed for international
[20:48.640 --> 20:54.540]  pandemics. As mentioned earlier, it's been proposed that lease lines could be used to transmit data
[20:54.540 --> 20:59.960]  from RSCs back to data hubs. If you're sending potentially sensitive data over third-party lines,
[20:59.960 --> 21:04.480]  you probably want to try and encrypt it and sign it so that it cannot be read or tampered whilst
[21:04.480 --> 21:10.220]  it's in transit. From what I can tell, lease lines will be used only for data hub communications,
[21:10.220 --> 21:14.280]  though they're not going to be used for like sending data from one car to another, because
[21:14.280 --> 21:20.240]  that just wouldn't make sense. Finally, we get to the wireless local area networks.
[21:20.880 --> 21:25.240]  Small WLANs within vehicles are proposed, which allow users to get onto the internet via their
[21:25.240 --> 21:30.280]  vehicle. However, it's also been proposed that giant WLANs could be used to handle the majority
[21:30.280 --> 21:36.200]  of communications between CAV network nodes. To me, this proposed usage of wireless local area
[21:36.780 --> 21:42.160]  networks for data transmission between CAV nodes is super interesting. It's proposed that it will
[21:42.160 --> 21:48.720]  be enabled through the usage of a relatively new 802.11p standard OCB mode, and as always with this
[21:48.720 --> 21:54.760]  talk, I'll be talking more about that later. So now that you know about the transmission medium,
[21:54.760 --> 21:59.280]  what about the transmission protocols? Within CAV networks, there's two main types of message
[21:59.280 --> 22:04.600]  being sent between vehicles and other nodes, CAM and DENIM. CAM standing for cooperative
[22:04.600 --> 22:10.840]  awareness messages and DENIM being decentralized environmental notification messages. For those
[22:10.840 --> 22:18.140]  of you in the US, these are equivalent to DSRC basic safety messages, where BSM part one is about
[22:18.140 --> 22:25.500]  equivalent to CAM and part two is about equivalent to DENIM. So about CAM, as the name suggests, CAM
[22:25.500 --> 22:29.800]  are used for cooperative awareness. They're what let the vehicles know where each
[22:29.800 --> 22:34.920]  other are, so that they can move cooperatively. The CAM acts as a heartbeat for the vehicle, providing
[22:34.920 --> 22:40.400]  metrics on its current state. This includes things like the current time, the location, heading
[22:40.400 --> 22:45.980]  direction, speed, if the lights are on or not, all that sort of thing. The vehicles don't send these to
[22:45.980 --> 22:50.420]  anyone in particular, they just transmit it out into the world for anyone or anything to pick up.
[22:50.580 --> 22:55.440]  They're signed by the pseudonym certificates used within the CAV ecosystem, and I'll talk more about
[22:55.440 --> 23:00.300]  certificates later. The generation of CAM is controlled by the cooperative awareness basic
[23:00.300 --> 23:06.300]  service within the vehicle. The CA basic service also receives and processes CAM from other vehicles.
[23:06.660 --> 23:10.680]  DENIM, on the other hand, are used by vehicles to share an awareness of any events that may have
[23:10.680 --> 23:15.620]  occurred. An event could be that an accident has occurred ahead, or that the vehicle has detected
[23:15.620 --> 23:21.000]  the presence of ice on the road, that sort of thing. Interestingly, the DENIM standards also
[23:21.000 --> 23:25.540]  contains medical emergency flags. These are the things I spoke about earlier, whereby if the
[23:25.540 --> 23:31.080]  vehicle detects that the driver's had a heart attack or they're in a diabetic coma, it's got a
[23:31.080 --> 23:37.520]  specific DENIM message type to let the other cars around that driver know that that's what happened.
[23:37.520 --> 23:43.020]  So once a vehicle's detected an event, it creates a new event DENIM. This contains info on what the
[23:43.020 --> 23:47.940]  event type is, the geographic area of relevance for the event, and that includes details of what
[23:47.940 --> 23:52.520]  roads will lead up to encountering the event. This DENIM is transmitted out into the world where
[23:52.520 --> 23:57.780]  it's picked up by the DEN basic service of other vehicle nodes. When a vehicle picks up a DENIM,
[23:57.780 --> 24:02.140]  the onus is placed upon the receiving vehicle to decide the relevance of the message.
[24:02.260 --> 24:06.720]  So the vehicle will determine if it's within the geographic area of relevance for the event, or
[24:06.720 --> 24:12.540]  if it's even heading in the correct direction to encounter the event. If it is, the vehicle
[24:12.540 --> 24:17.640]  will update its internal records and automatically retransmits the DENIM onwards to other vehicles.
[24:17.680 --> 24:22.800]  If it's not relevant, it just ignores it. Based on this automatic forwarding, vehicles may be
[24:22.800 --> 24:28.140]  updated as to the existence of an event as soon as they enter the relevant area. Likewise, if the
[24:28.140 --> 24:33.640]  initially reporting vehicle leaves the area, the event is not forgotten. Vehicles might also
[24:33.640 --> 24:38.000]  provide updates to an existing event, even if they were not the first vehicle to report it.
[24:38.000 --> 24:42.940]  Likewise, vehicles may send a negation DENIM to report that an event has ended.
[24:46.360 --> 24:51.720]  As I said before, both CAV and DENIM are signed. The proposed certificate system in CAV
[24:51.720 --> 24:57.120]  is a little bit bonkers in my mind, and I'll describe it later. But the key point here is the
[24:57.120 --> 25:02.680]  messages are signed. They're not encrypted because CAVs don't join networks in the traditional sense.
[25:02.780 --> 25:07.700]  Because there's no network joining, it's all up to the CA and DEN basic services to verify
[25:07.700 --> 25:13.020]  the validity of all received messages. This could be problematic for a lot of reasons.
[25:13.280 --> 25:17.160]  It seems like it's going to be really easy to jam a given vehicle by just spamming out messages
[25:17.160 --> 25:21.960]  near it. Likewise, if an attacker could fuzz the basic service and find a message that would crash
[25:21.960 --> 25:26.200]  it, then there's little resiliency against potentially harmful messages within this
[25:26.200 --> 25:31.100]  environment. It wouldn't even matter if the vehicle was part of the network because it's
[25:31.100 --> 25:35.940]  up to the receiver to determine if the message is valid or not, if it's from an actual member
[25:35.940 --> 25:42.860]  of the network or from an actual vehicle, sorry. There's also no nonce values in CAM and DEN,
[25:42.860 --> 25:48.140]  so you've got your standard risks of replay attacks there. In these future networks, some
[25:48.140 --> 25:52.220]  of the information contained within CAM will be used within the intelligent roadway systems for
[25:52.220 --> 25:57.020]  deciding things like traffic flow. So say you're an ambulance, the traffic light behavior might
[25:57.020 --> 26:02.240]  automatically be updated to favor traffic coming from your direction. So why not just continually
[26:02.240 --> 26:07.520]  replay a packet capture of an ambulance? The closest thing to nonce values that's included
[26:07.520 --> 26:13.880]  already is timestamps. And these, in my mind, are kind of weirdly done as well. Epochs weren't good
[26:13.880 --> 26:20.320]  enough for these guys. What they've gone for is a system whereby the time from the start of 2004
[26:20.320 --> 26:27.820]  is taken in milliseconds, and then it's divided by two to the power of 16, or 65,536, which is
[26:27.820 --> 26:32.100]  coincidentally a touch over the number of milliseconds in a minute. The remainder is
[26:32.100 --> 26:37.440]  then untransmitted. So whilst you could kind of use this in your application as a nonce value,
[26:37.440 --> 26:41.060]  you'd have something that could be replayed roughly every minute or so, depending on your
[26:41.060 --> 26:46.280]  tolerances. But yeah, this slightly weird timeliness metric makes it very hard to discern
[26:46.280 --> 26:51.760]  the liveliness of messages at a glance. So go ahead with those replay attacks. Another issue
[26:51.760 --> 26:55.840]  stems from the automatic forwarding of DENIM if the receiving vehicle is within the area of
[26:55.840 --> 27:02.980]  relevance. Like I mentioned, DENIM describe an event. Vehicles can automatically retransmit
[27:02.980 --> 27:07.660]  received DENIM. So now something interesting about these cab networks is that a mechanism
[27:07.660 --> 27:13.220]  is proposed to exist for detecting and punishing malicious behavior. The details of it aren't
[27:13.220 --> 27:17.820]  really specified in any great detail, but the general gist of it is that nodes can automatically
[27:17.820 --> 27:22.980]  report that certain vehicle sending out malicious data with the vehicle being identified by its
[27:22.980 --> 27:28.360]  signing certificate. It's unclear how many reports are needed to trigger a ban in the network.
[27:28.400 --> 27:33.240]  But yeah, after a certain threshold of reports are hit, a vehicle certificate will be temporarily
[27:33.240 --> 27:43.180]  rescinded. This means that other nodes won't see its messages as valid, and so will disregard them.
[27:43.820 --> 27:51.300]  So now, when a vehicle automatically forwards on a DENIM, it repackages the message. The sender ID
[27:51.940 --> 27:57.620]  that you received of the initial message is then replaced with the sender ID of the vehicle that's
[27:57.620 --> 28:03.420]  forwarding on the message, and it's re-signed using the re-sender certificate. And I mean, can you see
[28:03.420 --> 28:07.960]  where I'm going with this? Say the threshold of reports was five. If you could have five vehicle
[28:07.960 --> 28:13.220]  nodes that you control send out DENIM-containing malicious data near a target, it in theory would
[28:13.220 --> 28:17.960]  just repeat them all on. That vehicle would hit the ban threshold quite easily and would be banned
[28:17.960 --> 28:23.140]  from the network. Suddenly, it's denied access to the CAV network. Generally, I think that
[28:23.140 --> 28:26.960]  mechanisms such as automatic bans need to be carefully considered because there's, you know,
[28:26.960 --> 28:36.760]  there's a real potential for abuse in there. So how do we transmit these CAM and DENIM?
[28:37.980 --> 28:42.180]  Ad-hoc networking is required for the CAV networks because of the node's tendency to move around
[28:42.180 --> 28:48.520]  quite a bit at high speeds. The idea of having passing vehicles connect to RSUs as they go past
[28:48.520 --> 28:53.360]  has been floated, but it was written off because there wouldn't be sufficient time, apparently.
[28:53.360 --> 29:00.680]  I'm not sure how fast people think future cars are going to go, but... So I must apologize, it's now
[29:00.680 --> 29:05.700]  time for acronym o'clock. I'll try and make this as clear as possible, but if you're confused at all,
[29:05.700 --> 29:10.460]  just ask me questions afterwards and hopefully I can explain it a bit better. So to create these
[29:10.460 --> 29:17.960]  ad-hoc networks, the usage of 802.11p standard and OCB mode is proposed. So what's an 802.11p OCB?
[29:18.520 --> 29:24.940]  802.11 is an IEEE standard for network access control. It provides the authentication mechanisms
[29:24.940 --> 29:30.000]  for devices wishing to join a LAN or WLAN, as well as allowing for things like network
[29:30.000 --> 29:35.400]  decongestion to automatically take place. It's the stuff your home Wi-Fi network probably uses.
[29:35.620 --> 29:40.660]  So on top of the initial standards, it's 802.11p, which has been specifically designed for vehicle
[29:40.660 --> 29:46.960]  networks. It's licensed for use in the US's WAVE systems and in Europe's ITS G5 communication
[29:46.960 --> 29:52.900]  networks. It's been allocated the frequency band of 5.9 gigahertz. It's all fairly standard so far,
[29:52.900 --> 29:58.400]  but we need to have ad-hoc networks. My home Wi-Fi isn't ad-hoc. I need to connect devices to it.
[29:58.400 --> 30:05.180]  How does this work with these cars? So in this case, the 802.11p is being used in OCB mode,
[30:05.180 --> 30:11.280]  which means outside context of BSS or basic service set. Basic service set refers to the
[30:11.280 --> 30:16.420]  collection of things which can communicate with each other when in 802.11 network.
[30:16.420 --> 30:20.360]  When you join things to your home Wi-Fi network, they become part of the BSS.
[30:20.560 --> 30:25.740]  And then messages sent within the network are tagged with a BSS ID or basic service set ID,
[30:25.740 --> 30:30.340]  which marks them as belonging to the WLAN, so that all the nodes know if they're actually coming
[30:30.340 --> 30:35.500]  from something within the network and should be, you know, something they should bother with or not.
[30:36.600 --> 30:42.440]  In 802.11p OCB mode, we don't want any of that. We want everything to be able to transmit to
[30:42.440 --> 30:47.500]  everything else with no need to join the network. This allows for the truly ad hoc networking,
[30:47.500 --> 30:52.480]  which is required for CAM and DENIM to just be spat out and have everyone listen to them.
[30:52.760 --> 30:56.740]  No authentication is required to be able to transmit within these new networks.
[30:56.740 --> 31:00.620]  So it's up to the receiver to investigate the signing certificate and assess if the
[31:00.620 --> 31:05.600]  messages are valid or not. But also, because there's no joining to a network, there's no
[31:05.600 --> 31:10.120]  inbuilt decongestion, apart from some basic polling and automatic rate adjustment.
[31:10.120 --> 31:13.160]  Can you see where that might lead to some problems?
[31:14.640 --> 31:19.580]  If you said denial of service, you'd be right. What we've got here is the frequency allocations
[31:19.580 --> 31:27.580]  for ITSG5. The EU has provided permissions for ITSG5 transmissions within the 5.47 to 5.925
[31:27.580 --> 31:33.680]  gigahertz range. The nice big, you see that nice big band on the left of the diagram? That's for
[31:33.680 --> 31:39.420]  broadband radio access networks, radio local area networks, and wireless local area networks.
[31:40.340 --> 31:45.640]  The key point for this is that you need to make use of dynamic frequency selection to avoid
[31:45.640 --> 31:51.220]  co-channel interference if you want to transmit in that range, which, since our CAVs networks
[31:51.220 --> 31:56.360]  aren't going to be connecting to the WLAN in the traditional sense, they cannot. So basically,
[31:56.360 --> 32:00.680]  you've already limited yourself from using a large chunk of the bands you've got available to you.
[32:00.840 --> 32:06.080]  Next up, you've got your little DSRC band in the middle. Well, that's not for ITSG5,
[32:06.080 --> 32:12.760]  so we can't use that. On the far right, we've already got a little band 5.905 to 5.925 gigahertz
[32:12.760 --> 32:18.920]  that's reserved for future use. So basically, the CAV networks are only left with 5.88 to 5.905
[32:18.920 --> 32:24.840]  gigahertz ranges. And I hear there's a lot of cars in general, like there's a lot of them,
[32:24.840 --> 32:29.020]  they tend to all get together on these big stretches, and there's just a lot of them all
[32:29.020 --> 32:34.940]  talking at once. So and then there's also there's going to be like a shit ton of sensors on top of
[32:34.940 --> 32:43.590]  that, too. It doesn't seem like it's going to go well, really. So the proposed ad hoc networks in
[32:43.590 --> 32:48.270]  CAV networks are pretty unique, because it removes the issues from everything having to be joined to
[32:48.270 --> 32:52.830]  the network. And there's a certificate infrastructure in place, you can still verify the validity and
[32:52.830 --> 32:58.210]  integrity of received messages, at least. But that's the problem. When people aren't having
[32:58.210 --> 33:03.190]  to join a network, it means anyone can transmit, you got to process every single message you
[33:03.190 --> 33:07.570]  receive to work out if it's valid or not. I think that in these future CAV networks, denial of
[33:07.570 --> 33:12.610]  service attacks are going to be a real big issue, both on the frequency jamming front, but also from
[33:12.610 --> 33:17.870]  inducing the vehicles to process large quantities of junk messages. It doesn't even have to be
[33:17.870 --> 33:22.270]  junk, really. With the automatic forwarding of denim, you wouldn't need to have many cars in an
[33:22.270 --> 33:27.710]  area to get a good packet storm going. If we decide to go with the scenario whereby roadside units can
[33:27.710 --> 33:32.930]  be used to teleoperate autonomous vehicles, it's going to go kind of badly. It just does not seem
[33:32.930 --> 33:39.510]  like a good idea. Ideally, no vehicle should need to be connected to the CAV networks to operate.
[33:39.510 --> 33:43.770]  What's being joined would increase the efficiency of operations, each vehicle should be capable of
[33:43.770 --> 33:53.790]  operating without receiving any data from external sources. So now I'm going to finally talk about
[33:53.790 --> 33:58.930]  the proposed usage of public key infrastructure and vehicle certificates. The European Commission
[33:58.930 --> 34:05.050]  has proposed an entire public key infrastructure or PKI for the CAV networks. In their proposals,
[34:05.050 --> 34:10.630]  they're keen to stress that it's just a proposal, not gospel. But honestly, it's fairly standard
[34:10.630 --> 34:15.010]  stuff really in the proposal. At the top, you've got your route certificate authority and the
[34:15.010 --> 34:20.150]  proposals describe in great detail how to physically secure these. There's fairly standard encryption
[34:20.150 --> 34:25.070]  schemes, you know, they're making use of AES 128. I'm not going to go into too much details on the
[34:25.070 --> 34:33.230]  PKI since it's all fairly standard from what I could tell. The vendors will have their own
[34:33.230 --> 34:39.010]  which they'll use to sign vehicle sets before the vehicle is sold. These preloaded sets are
[34:39.010 --> 34:46.010]  known as enrollment credentials. Once a vehicle is sold now on the road, it uses its
[34:46.010 --> 34:51.150]  enrollment credentials to request access tokens, which are also known as pseudonyms. And this
[34:51.150 --> 34:57.330]  request goes via the roadside units and the pseudonyms are returned via the roadside units.
[34:57.330 --> 35:04.410]  So pseudonyms are where things get really weird in my mind. The creator of the cab networks heard
[35:04.410 --> 35:08.730]  that privacy is a good thing, and they want to maintain it within these networks, which you know,
[35:08.730 --> 35:14.610]  so far so good. It's a good idea. They then decided that it would be bad for vehicles to
[35:14.610 --> 35:19.910]  transmit a unique identifier, because then someone could track them. I think they forgot
[35:19.910 --> 35:26.750]  that license plates are a thing, but let's put that aside for now. When a vehicle uses its
[35:26.750 --> 35:32.030]  enrollment credentials to request pseudonyms, it's given a pool of 100 of them. These are valid
[35:32.030 --> 35:36.930]  for a period of one week. The pseudonyms are used to sign all the cam and denim that the vehicle
[35:36.930 --> 35:42.170]  sends out, so they can be verified. Pseudonyms are designed to be rapidly changing. On the slides,
[35:42.170 --> 35:46.210]  I've got the recommendations that come from the European Commission on when you should cycle
[35:46.210 --> 35:52.570]  pseudonym. And they're kind of weird. So when you start the car, you cycle to a new pseudonym.
[35:52.570 --> 35:58.330]  You change again after driving in the region of 800 to 1500 meters, then again somewhere after
[35:58.330 --> 36:03.810]  two to six meters, then again after 15 kilometers. And it's just so arbitrary. Like, why are we
[36:03.810 --> 36:08.930]  switching between distance and time? Like, it's weird. But potentially, you could be cycling
[36:08.930 --> 36:13.710]  through quite a lot of them on one road trip. And you've got a pool of 100 pseudonyms to use, right?
[36:13.710 --> 36:18.610]  And that's got to last you a week. There's a bit of disparity on what happens when you run out.
[36:18.870 --> 36:22.470]  According to Etsy, you should request a new pool of 100 once you run out.
[36:22.570 --> 36:26.610]  The European Commission, however, states that you can just reuse your pool of 100 so long as
[36:26.610 --> 36:31.590]  they're still within the validity period. But not everyone is always in range of the infrastructure
[36:31.590 --> 36:36.190]  needed to get more pseudonyms. Because of this, it's possible for vehicles to be preloaded with
[36:36.190 --> 36:42.110]  up to three months' worth of future dated pseudonyms. I mean, what are the practicalities
[36:42.110 --> 36:47.430]  of pseudonym cycling? When a vehicle cycles to its next pseudonym, it also needs to update its
[36:47.430 --> 36:52.590]  IP address. Otherwise, you could trivially track the vehicle for these changes.
[36:52.630 --> 36:57.570]  The standards documentation recommends the usage of stateless address auto-configuration,
[36:57.570 --> 37:05.910]  as described in RFC 4862. So RFC 4862 provides a framework for devices in a network to automatically
[37:05.910 --> 37:10.650]  configure themselves using a mixture of information being advertised by a router
[37:11.190 --> 37:16.350]  and from locally available information. This allows the nodes to communicate directly between
[37:16.350 --> 37:20.350]  each other without needing to go through a router, which is appropriate here.
[37:20.930 --> 37:26.450]  CAVs are intended to use IPv6 addresses. As this address space is quite large, there's a low risk
[37:26.450 --> 37:33.370]  of collision in the pseudo-randomly generated IPv6 addresses created using RFC 4862. But to avoid
[37:33.370 --> 37:40.450]  collision, RFC 4862 nodes do advertise their proposed new IPv6 addresses and give neighbors
[37:40.450 --> 37:44.870]  the chance to respond if they've already claimed them. So what's to stop an attacker using this
[37:44.870 --> 37:48.910]  to track a vehicle's IP address changes? I mean, not much really, so long as you were keeping near
[37:48.910 --> 37:53.430]  the vehicle. Or just look at the MAC addresses. These are not cycled at the same time as the IP
[37:53.430 --> 37:57.930]  addresses. Or more interestingly, what if you always claimed that you were already using the
[37:57.930 --> 38:03.350]  IPv6 address that it's advertising? Like, could you just make a little box that you can tape onto
[38:03.350 --> 38:10.010]  the vehicle, a little address denial box, which automatically lays claim to any address being
[38:10.010 --> 38:14.690]  advertised by the vehicle? Again, I think that just denial of service attacks are going to be
[38:14.770 --> 38:21.930]  a big thing in these future CAV networks. In my mind, pseudonym cycling seems more likely to enable
[38:21.930 --> 38:26.890]  abuse than to protect privacy. As I mentioned before, there are provisions for vehicles to be
[38:26.890 --> 38:31.610]  automatically banned from the CAV network via their certificate being revoked. The certificates being
[38:31.610 --> 38:36.150]  revoked would potentially just be their pseudonym. So the attacker can either reduce the pseudonym
[38:36.150 --> 38:41.990]  cycle via normal driving or potentially manipulate their system into cycling on demand. It's an ideal
[38:41.990 --> 38:47.090]  method of ban evasion, really. To combat this, it's been suggested that hardware-trusted
[38:47.090 --> 38:51.770]  components could be used to provide more robust banning mechanisms. This could be used to wipe the
[38:51.770 --> 38:56.390]  entire pool being stored on the vehicle. But then you still got the problems I talked about earlier,
[38:56.390 --> 39:01.290]  whereby you can just cause a vehicle to be unjustly banned from the network. Also, I'm kind of always
[39:01.290 --> 39:09.130]  wary of placing too much trust in anything that's sold as unhackable. It just seems like a
[39:09.130 --> 39:14.090]  bull's eye on it. And there's nothing to say that an attacker would need to control multiple
[39:14.090 --> 39:18.550]  vehicles even to be able to gain malicious levels of influence within the CAV networks.
[39:18.950 --> 39:23.750]  I mean, Tesla's already had issues with all parts of head units appearing on eBay unwiped.
[39:23.810 --> 39:29.250]  It's likely that whatever contains the CAV, the CA slash then basic service will appear soon
[39:29.250 --> 39:34.410]  enough, harvested from written off cars by unscrupulous garages. Just pick up a couple
[39:34.410 --> 39:38.750]  of these and you're good to go with your civil attacks. They might come preloaded with three
[39:38.750 --> 39:42.990]  months of certs, or maybe they'll still be able to gain new certs from the network. It might not
[39:42.990 --> 39:46.490]  be the case that the vendor knows the car was written off so its enrollment credentials were
[39:46.490 --> 39:51.050]  not revoked. You know, use these to your heart's content to avoid bans and juice bans and others,
[39:51.050 --> 39:55.630]  flood networks and malicious data, whatever you feel like really. Or you could use these to send
[39:55.630 --> 40:00.790]  out your CA slash then basic service crashing messages that you know you've developed previously
[40:00.790 --> 40:05.990]  by fuzzing the basic services. Or if you could gain access to multiple pseudonyms at once,
[40:05.990 --> 40:10.690]  use them to simulate other vehicles. You got someone tailgating you? Start sending out spoofed
[40:10.690 --> 40:14.830]  CAVs signed with one of your other pseudonyms, simulating a vehicle following behind you.
[40:14.830 --> 40:19.370]  The tailgater's car might think there's a car in that space already and automatically fall back.
[40:21.760 --> 40:26.660]  The final major component of the CAV ecosystem that I want to talk about is test beds.
[40:26.820 --> 40:31.960]  These are regions of roadway which vendors can test their new products on. They can include a
[40:31.960 --> 40:36.560]  mixture of private roads and public roads, and they will be absolutely covered in sensors so
[40:36.560 --> 40:42.080]  vendors can receive their high quality trials data. In current proposals, vendors will be able
[40:42.080 --> 40:51.880]  to buy access to data from specific regions of test beds at specific times.
[40:51.940 --> 40:57.140]  It's been suggested this could be facilitated using a web interface which comes with its own
[40:57.140 --> 41:02.280]  issues really. I mean generally the security of these test beds is going to need to be very high.
[41:02.280 --> 41:06.220]  Vendors will be testing new products which competition might want to get a sneak peek of.
[41:06.220 --> 41:10.520]  There's also the very real possibility that the vehicles being tested on these test beds might not
[41:10.520 --> 41:15.660]  yet have the most robust security in place. So it's important that these potentially insecure
[41:15.660 --> 41:22.500]  vehicles cannot be used as vectors into the rest of the CAV network. I'm now going to move on to
[41:22.500 --> 41:26.740]  talk about some of the threats that F-Secure thinks CAV networks will face and talk you through a
[41:26.740 --> 41:31.760]  couple examples of how these could be actualized. If this is an area of interest to you, I'd recommend
[41:31.760 --> 41:36.040]  reading our full white paper as it goes into much more detail about the type of assets which
[41:36.040 --> 41:41.580]  will be considered within CAV networks, as well as talking about specific threat actor groups
[41:41.580 --> 41:53.930]  including APT32. So here's a rough overview of the threat actors that are likely to target the CAV
[41:53.930 --> 42:01.890]  networks. At the bottom we've got the most prolific type of hacker, the script kiddie or skiddie.
[42:02.190 --> 42:06.570]  These are just people sat at home, they're just playing around, they downloaded something off
[42:06.570 --> 42:10.090]  the internet, they've got their low orbit iron cannon, they want to have a play with it, they're
[42:10.090 --> 42:16.710]  trying to impress their mates. They are low skill, but they are prolific. And they might target the
[42:16.710 --> 42:22.230]  CAV networks just because, you know, it seems a bit for the lulz, seems fun. Above this tier,
[42:22.230 --> 42:27.370]  you've got the motivated individuals or hacktivists. These guys actually know what
[42:27.370 --> 42:32.670]  they're doing. They'll quite often be using free tools, or maybe they found some bespoke tools,
[42:32.670 --> 42:36.750]  maybe they even wrote some stuff on their own. But they tend to be more disgruntled people who
[42:36.750 --> 42:43.890]  are ideologically motivated. So like you get the people who are hacking SeaWorld, Sealand,
[42:43.890 --> 42:47.330]  they won in the US because they were pissed off about the treatment of orcas.
[42:47.470 --> 42:50.810]  Yeah, it's just people trying to rebel against something that they don't like.
[42:51.550 --> 42:55.870]  Above this tier, you've got the kind of fairly standard criminal groups. They tend to be going
[42:55.870 --> 43:01.470]  for financial gain. This could be just a small group that's created, say, a piece of ATM malware.
[43:01.470 --> 43:05.310]  Like they often they might just have one techie who creates stuff and then the rest of the money
[43:05.310 --> 43:10.370]  mules that go around picking up the cash, that sort of thing. They tend to have more cash available
[43:10.370 --> 43:16.630]  than the tiers below. So they can actually buy bespoke tools on the dark market, or, you know,
[43:16.630 --> 43:21.110]  fund someone to create tools that are a bit more interesting. Above that tier, you've got serious
[43:21.110 --> 43:26.230]  organized crime groups. These guys have a lot of technical know-how, or at least access to people
[43:26.230 --> 43:31.450]  and the technical know-how. They've also got access to large amounts of resources, so they can
[43:31.450 --> 43:36.070]  kind of do what they want, really. You know, they're going to be able to fund people to research
[43:36.070 --> 43:40.610]  zero days that are targeting certain technology that they're interested in, all that sort of thing.
[43:41.130 --> 43:46.270]  Above this, you've got the nation-state threats. So these guys, their aim is not always financial,
[43:46.270 --> 43:51.010]  although it can occasionally be. These guys tend to go more for intelligence gathering,
[43:51.010 --> 43:57.250]  industrial espionage, economic destabilization. They tend to be using advanced tools. You know,
[43:57.250 --> 44:01.910]  they might even be stealing tools from governments. They'll be using endless zero days.
[44:02.050 --> 44:07.110]  Generally, there's not too many of them, but when they target you, you're going to have a bad time.
[44:07.110 --> 44:11.570]  They're very hard to deal with because they have so many resources and technical expertise
[44:11.570 --> 44:16.570]  at their disposal. And again, we think that people at all these levels are likely to target
[44:16.570 --> 44:22.630]  the CAV networks. And frankly, there's no way to keep everyone out. People who have the absolute
[44:22.630 --> 44:27.250]  dedicated skills and resources, they probably will try and figure a way, they probably will
[44:27.250 --> 44:31.630]  be able to find a way in. But it's important to keep these lower tiers out. You know, you
[44:31.630 --> 44:37.610]  shouldn't be able to have the skiddy take down your networks. It's not good. The best way to
[44:37.610 --> 44:42.450]  counter it really is to just have good detection. So even if a nation-state was able to do something
[44:42.450 --> 44:46.590]  to your network, by being able to detect it immediately, you can start to go into damage
[44:46.590 --> 44:50.910]  control mode, you can start to ignore data coming from that node because you know it's malicious,
[44:50.910 --> 44:57.370]  that sort of thing. There's a whole variety of assets that these threat actors are likely to
[44:57.370 --> 45:02.270]  be targeting within the networks for various different, you know, end goals. So you've got the
[45:02.270 --> 45:06.650]  physical ones, which are the obvious things like you've got vehicles, you've got the roadside units
[45:06.650 --> 45:13.050]  and sensors, but you could also target, say, a garage so that you could perhaps automatically
[45:13.050 --> 45:18.390]  lift data of everything that comes into the garage. Or the backend servers, if the car is still
[45:18.390 --> 45:24.270]  connected to the vendor servers in some way, could you pivot from the vehicle into the vendor
[45:24.270 --> 45:29.670]  servers and, you know, do your cyber crimes through there. We've also got the electronic vehicle
[45:29.670 --> 45:34.330]  charging stations. Those are an interesting target. If you could break those, you could cause quite a
[45:34.330 --> 45:40.790]  bit of harm, cause a lot of people to be stranded. You've got your public key infrastructure facilities,
[45:40.790 --> 45:44.470]  like the actual buildings they're stealing them at. If you could get in and steal, you know, the
[45:44.470 --> 45:50.490]  route certificate, you can have some fun with that. On the digital front, you've got sensor data,
[45:50.490 --> 45:56.370]  regional events data, so things like weather, you've got your traffic data. You've also got personal
[45:56.370 --> 46:01.390]  information probably carried upon these vehicles, like there's the classic of buying old GPS units
[46:01.390 --> 46:05.670]  and, you know, pressing the home button because, you know, people have programmed home into them.
[46:05.670 --> 46:10.350]  Or if you steal a car, you just tell the GPS to send you home and, you know, you can get in like that.
[46:11.670 --> 46:16.290]  Within things like testbed results, there's also likely to be financially sensitive information,
[46:16.290 --> 46:20.690]  or even intellectual property. People could actually get any interesting data off of these
[46:20.690 --> 46:25.690]  vehicles, perhaps off the infotainment systems. There might be some proprietary systems that
[46:25.690 --> 46:31.130]  an attacker could gain information about. On top of these assets, you've also got the kind of
[46:31.130 --> 46:38.330]  intrinsic reputational assets. So things like Tesla's been getting hammered a bit in the US
[46:38.330 --> 46:43.770]  news recently, because of stuff like people putting autopilot on and the car driving into a barrier,
[46:43.770 --> 46:48.770]  or I can't remember which company it was, was trialing a couple years back, one of their
[46:48.770 --> 46:54.810]  self-driving vehicles that killed a pedestrian. And, you know, it's causing reputational harm
[46:54.810 --> 47:05.240]  is a real risk in these areas, you don't want that. So as an example threat,
[47:05.960 --> 47:11.480]  I'm going to talk about Bob the Grumpy Guy. Bob lives in a small village, which has a section of
[47:11.480 --> 47:16.140]  smart roadway running through it. He's upset by the speed at which cars travel through the village,
[47:16.140 --> 47:21.080]  and he wants them to slow down. He's read online that the roadside units placed every 500 meters
[47:21.080 --> 47:25.160]  along the roadside control the speed of which cars drive, so he decides he's going to target them.
[47:25.400 --> 47:29.980]  He goes online and he spends some time learning about hardware security. One night he takes his
[47:29.980 --> 47:35.460]  laptop and a crowbar to an RSU, which is hidden behind some trees. The RSU is in a locked cabinet,
[47:35.460 --> 47:40.520]  but Bob manages to leave it open with his crowbar. The physical tamper detection system on the RSU
[47:40.520 --> 47:45.220]  detects the unexpected opening of the door and sounds an alarm. An alert is sent to the cab
[47:45.220 --> 47:51.440]  network requesting investigation. The loud alarm startles Bob and he runs back home. Based on his
[47:51.440 --> 47:55.480]  experience with the roadside unit, Bob decides he's going to try and use other devices to get
[47:55.480 --> 48:01.080]  to the RSU. His neighbor, conveniently, has bought a brand new intelligent vehicle, which connects to
[48:01.080 --> 48:06.500]  these RSUs. Bob does some research on his neighbor's new car and he discovers that the car broadcasts
[48:06.580 --> 48:11.180]  a hotspot which drivers can connect their phones to. Bob reads a web forum and finds unofficial
[48:11.180 --> 48:16.360]  reports saying the technology used for this hotspot has an abusable authentication vulnerability.
[48:17.420 --> 48:22.600]  As Bob's house is within the hotspot's range, he exploits the vulnerability to connect to the car
[48:22.600 --> 48:26.920]  from his bedroom. Using his knowledge of network security, he's able to pivot through the car's
[48:26.920 --> 48:31.720]  internal networks until he finds the service which allows it to connect interface with the RSU.
[48:31.820 --> 48:36.400]  After some trial and error, he learns how to send status update messages to the nearby RSU.
[48:36.580 --> 48:40.640]  Bob uses these to send the RSU many reports that the vehicle is covered,
[48:40.640 --> 48:45.640]  sorry, that the road is covered in black ice. The RSU collates these reports and does not correctly
[48:45.640 --> 48:51.080]  identify that they have all come from a single vehicle. The RSU updates its models for that
[48:51.080 --> 48:55.180]  area with the presence of black ice and decides that the speed limit in that area should be
[48:55.180 --> 48:59.880]  lowered. The dynamically updated road signs along the village now display half the previous speed
[48:59.880 --> 49:05.480]  limit. Autonomous vehicles automatically adhere to them, and most manually driven cars do.
[49:05.620 --> 49:10.840]  Bob is happy once again. His village is nice and quiet and has slow cars going through it.
[49:12.880 --> 49:18.480]  Next up, we'll talk about an imaginary threat from a malicious nation state.
[49:18.680 --> 49:23.600]  So the country of Zeron spends a lot of time comparing itself to its neighbor Nerund.
[49:23.600 --> 49:29.060]  Nerund has a highly developed ITS roadway system with many internationally acclaimed
[49:29.060 --> 49:33.560]  CAV developers based in the country. Zeron decides it would like to have more developed
[49:33.560 --> 49:38.860]  ITS roadways too, but it doesn't have the resources to fund the extensive CAV development work Nerund
[49:38.860 --> 49:43.780]  has done. Zeron decides corporate espionage would be a much more cost-effective measure
[49:43.780 --> 49:51.700]  for developing its technical capabilities. Zeron government engages APT32, a Zeron-backed
[49:51.700 --> 49:56.160]  hacking group. This group is tasked with stealing as much information on CAV as possible from
[49:56.160 --> 50:01.780]  companies in Nerund. The APT77 team decides their first move should be to gain access to
[50:01.780 --> 50:07.140]  the internal networks of Nerund Auto, the country's leading vehicle manufacturer. A spearfishing
[50:07.140 --> 50:12.720]  campaign is launched, and APT77 soon finds itself with footholds within various support functions of
[50:12.720 --> 50:20.140]  Nerund Auto. APT77 discovers Nerund Auto does not make use of network segregation. The group can
[50:20.140 --> 50:24.940]  move from an HR employee's computer to one belonging to the tech support team. This tech
[50:25.490 --> 50:31.000]  support team has access to the research and development team networks. Once APT77 gains
[50:31.000 --> 50:36.060]  access to Nerund Auto's R&D network, they're able to steal large amounts of research work, including
[50:36.060 --> 50:41.320]  plans for unreleased vehicles. The Zeron government is very happy with their information gathered by
[50:41.320 --> 50:47.500]  APT77. They ask APT77 to see if their foothold within the Nerund Auto networks can be
[50:47.500 --> 50:52.540]  leveraged to gain access to a given car. The group quickly discovers that through the remote upgrade
[50:52.540 --> 50:57.640]  functionality implemented in all Nerund Auto products, they may push malicious code to arbitrary
[50:57.640 --> 51:04.380]  vehicles. The Zeron government provides APT32 with details of a Nerund Auto brand vehicle
[51:04.380 --> 51:10.740]  owned by a key Nerund politician. The APT77 group confirms they can push code to this vehicle.
[51:10.740 --> 51:16.720]  As the code comes from the trusted manufacturer, it is not evaluated. The APT group is able to cause
[51:16.720 --> 51:22.060]  the politician's car to take arbitrary actions. It's not really what you want.
[51:24.120 --> 51:28.780]  So, I mean, these are all proposals at this point. They're not things that are existing
[51:28.780 --> 51:33.380]  in the real world in this state quite yet, thankfully. What can we do at this point?
[51:35.680 --> 51:39.780]  Generally, I think we need a lot more security research within this area.
[51:40.700 --> 51:45.140]  There's still plenty of time to address them. I mean, especially with the UK government's
[51:45.140 --> 51:49.580]  idea of this being the next 10 years. And hopefully the outputs of this project and
[51:49.580 --> 51:54.200]  the other ZenZip projects will help to inform the future decision-making process.
[51:56.180 --> 52:01.220]  So, while we were going over all these standard documents, I'll just count the amount of times
[52:01.220 --> 52:06.960]  that I read security is out of scope for this document or security will occur at another level.
[52:07.700 --> 52:11.460]  People really need to stop doing this. You need to consider the security at every level,
[52:11.460 --> 52:16.160]  in my mind, to make sure that the systems are kind of holistically as secure as possible.
[52:16.840 --> 52:20.080]  I also think they should take more input from cybersecurity people.
[52:20.320 --> 52:24.940]  I mean, generally, you, dear watcher of this talk, take a look at these technologies yourselves.
[52:25.160 --> 52:30.140]  The 802.11p OCB mode seems to be very under-researched. There's not that much information
[52:30.140 --> 52:34.260]  available on it. But it seems super weird. It seems like there's going to be a lot of potential
[52:34.260 --> 52:39.840]  for abuse. And it seems like you can do a lot of cool stuff with it. Incidentally, if you happen
[52:39.840 --> 52:45.980]  to have access to any tech that actually can use it, is already set up to communicate over 802.11p
[52:45.980 --> 52:51.560]  OCB mode, please do reach out to me on Twitter or email. F-Secure is quite keen to get hands on
[52:51.560 --> 52:57.500]  with it. We want to collaborate. Or, you know, just generally chat about 802.11p. It's interesting
[52:57.500 --> 53:04.500]  stuff. I think the testing at scale is going to be a really big problem. These networks are going
[53:04.500 --> 53:08.960]  to be absolutely huge. They're probably going to become part of our critical national infrastructure.
[53:08.960 --> 53:13.800]  And they're going to get popped, for sure, at some point. But we still need to remove the low
[53:13.800 --> 53:17.980]  hanging through. We don't want the little script kiddies to be able to take bits of the network
[53:17.980 --> 53:23.000]  down. We don't want Bob to be able to mess with speed limits just because he's annoyed by the fast
[53:23.000 --> 53:30.120]  cars. And in the case that something does happen, a breach is detected, we need to be able to address
[53:30.120 --> 53:35.560]  them. So we were proposing a system whereby we can detect the point at which malicious data has
[53:35.560 --> 53:42.540]  entered into the network. So this would be by re-signing your data at every point of transmission.
[53:42.880 --> 53:48.000]  So your vehicle, it signs the data when it sends it on, right? This ends up in the roadside units.
[53:48.000 --> 53:53.460]  The roadside unit collates all this data, and then it signs the bundle of data before it transmits
[53:53.460 --> 53:59.020]  it onwards to the data hub. Then the data hub collates all this information. And then you
[53:59.020 --> 54:03.260]  notice that something's a bit wrong or something's malicious. You can then look at the initial data
[54:03.260 --> 54:08.120]  and say, okay, well, the malicious data include this signed bundle come from the RSUs, that RSU,
[54:08.120 --> 54:12.700]  so it's come from that RSU. And then that RSU, you can work backwards and be like, okay, well,
[54:12.700 --> 54:17.260]  it's been signed by this vehicle. And it's just important to be able to backtrace the point at
[54:17.260 --> 54:22.120]  which the incident has occurred, so that you can try and prevent better things, these things from
[54:22.120 --> 54:27.020]  happening again in the future. Like if you notice it's a specific RSU, go investigate that RSU,
[54:27.020 --> 54:30.840]  work out how it got popped so that you can better protect the other nodes within the network.
[54:33.500 --> 54:37.080]  In general, I think that information sharing is going to be really important.
[54:37.120 --> 54:41.580]  There seems to be this thing of cybersecurity being a competitive advantage. You know,
[54:41.580 --> 54:46.600]  it's, it's, it's like considered IP almost that you know how to not get hacked. And I don't think
[54:46.600 --> 54:50.920]  that should be the case. I think there should be better information sharing between the vendors,
[54:50.920 --> 54:57.140]  and even between like research groups. Because if, say you had a phishing campaign targeting your
[54:57.140 --> 55:02.220]  organization as a vendor, it's likely that the attackers will also target similar vendors.
[55:02.220 --> 55:06.220]  So by sharing information between each other, you can be better prepared for these attacks to come
[55:06.220 --> 55:10.800]  in. And you know, if someone does manage to get into your network, you can share that information
[55:10.800 --> 55:15.360]  with other companies so that it doesn't happen to them either. I think you need to get, we need to
[55:15.360 --> 55:19.640]  get over seeing it as like a competitive advantage and just work more collaboratively in general
[55:19.640 --> 55:26.980]  together. So my conclusions for this are current proposals are not fit for purpose, they're going
[55:26.980 --> 55:33.080]  to be a nightmare of just denial of service and all sorts. Just don't, just don't, don't do that.
[55:33.660 --> 55:37.300]  There needs to be more considerations for cybersecurity when designing these systems.
[55:37.300 --> 55:41.140]  Stop passing the buck on cybersecurity or you'll make baby Jesus cry.
[55:42.020 --> 55:45.400]  There's a lot of weird shit in these proposals that people should look at more.
[55:45.760 --> 55:52.360]  AO211 POCB mode is weird shit. Pseudonyms are even weirder shit. And lastly, I'm never getting
[55:52.480 --> 55:57.340]  a connected autonomous vehicle if you can help, if I can help it. Like I don't even get ones
[55:57.340 --> 56:02.060]  with lane assist. I don't trust it at all. I appreciate I'm in the wrong industry to be saying
[56:02.060 --> 56:10.500]  that, but I don't trust it. So before we finish, I just want to give a few acknowledgements.
[56:10.500 --> 56:14.320]  I'd like to say thanks to my colleagues who contributed to this project. The main contributors
[56:14.320 --> 56:20.660]  were Joel, Rich and Terry, who all worked heavily on the project. I'd also just like to thank
[56:20.660 --> 56:25.520]  my colleague Kytan, who, although he's no longer with us, he provided a lot of support to me while
[56:25.520 --> 56:32.140]  I was working on this project. Surrey University also gave us quite a bit of advice on cab networks
[56:32.140 --> 56:37.880]  while we were doing our research work. I'd also like to thank Zenzik for funding this work and
[56:37.880 --> 56:43.820]  F-Secure for letting me work on it, and KFC for fueling my existence. I was very upset while they
[56:43.820 --> 56:48.440]  were shut in the UK due to the lockdown, but they've reopened now. Everything's wonderful again.
[56:50.060 --> 56:56.080]  So that's the end of my talk. I think we're doing questions in the chat now, or you can tweet me on
[56:56.080 --> 57:02.740]  Twitter. I mainly shitpost, so yeah, but go for it. Or drop me an email. I've got my email address
[57:02.740 --> 57:08.460]  there. Thank you for your time. Thanks for watching, and feel free to ask me any questions.
